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Abstract 

In this paper, we propose a synchronous protocol with- 
out periodicity for scheduHng muhi-mode real-time sys- 
tems upon identical multiprocessor platforms. Our pro- 
posal can be considered to be a multiprocessor extension 
of the uniprocessor protocol called "Minimal Single Off- 
set protocol". 

1 Introduction 

Hard real-time systems require both functionality correct 
executions and results that are produced on time. Control 
of the traffic (ground or air), control of engines, control of 
chemical and nuclear power plants are just some examples 
of such systems. Currently, numerous techniques exist 
that enable engineers to design real-time systems, while 
guaranteeing the correctness of their temporal behavior in 
a systematic way. These techniques generally model each 
functionality of the system by a recurrent task, character- 
ized by a computing requirement, a temporal deadline and 
an activation rate. Commonly, real-time systems are mod- 
eled by a fixed set of such tasks. However, some applica- 
tions exhibit multiple behaviors issued from several op- 
erating modes (e.g., an initialization mode, an emergency 
mode, a fault recovery mode, etc.), where each mode is 
characterized by its own set of functionalities, i.e., its set 
of tasks. During the execution of such multi-mode real- 
time systems (described in details in ||9|), switching from 
the current mode (called the old-mode) to another one (the 
new-mode hereafter) requires to substitute the current ex- 
ecuting tasks with the tasks of the target mode. This sub- 
stitution introduces a transient stage, where the tasks of 
the old- and new-mode may be scheduled simultaneously. 
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thereby leading to an overload which compromises the 
system schedulability. 

The scheduling problem during a transition between 
two modes has multiple aspects, depending on the behav- 
ior and requirements of the old- and new-mode tasks when 
a mode change is initiated (see e.g., |l4][6l). For instance, 
an old-mode task may be immediately aborted, or it may 
require to complete the execution of its current instance in 
order to preserve data consistency. On the other hand, a 
new-mode task sometimes requires to be activated as soon 
as possible, or it may also have to delay its first activation 
until all the tasks of the old-mode are completed. More- 
over, it may exist some tasks (called mode-independent 
tasks) present in both the old- and new-mode, such that 
their periodic executions must be carried out indepen- 
dently from the mode change in progress. The existing 
transition scheduling protocols are classified with respect 
to their ability to deal with the mode-independent tasks 
and the way old- and new-mode tasks are handled during 
the transitions. In the literature (see 15] for instance), a 
protocol is said to be synchronous if it never releases the 
new-mode tasks before all the old-mode tasks have com- 
pleted their last instance, otherwise it is said to be asyn- 
chronous. Furthermore, a synchronous/asynchronous pro- 
tocol is said to be with periodicity if it is able to deal with 
mode-independent tasks, otherwise it is said to be without 
periodicity. 

Related work. Numerous scheduling protocols have al- 
ready been proposed in the wn/processor case to ensure the 
transition between two modes. In synchronous protocols, 
one can cite the Idle Time Protocol ifTOI where the periodic 
activations of the old-mode tasks are suspended at the first 
idle time-instant occurring during the transition and then, 
the new-mode tasks are released. The Maximum-Period 
Offset Protocol proposed in (21 is a protocol with period- 
icity which delays the first activation of all the new-mode 
tasks for a time equal to the period of the less frequent 
task in both modes (mode-independent tasks are not af- 
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fected). The Minimum Single Offset Protocol in ||9l com- 
pletes the last activation of all the old-mode tasks and 
then, releases the new-mode ones. This protocol exists 
in two versions, with and without periodicity. Concerning 
the asynchronous protocols, the authors of ifTTl propose a 
protocol with periodicity and the authors of ||8]|2l propose 
a protocol without periodicity. 

To the best of our knowledge, no protocol exist in 
the muZf/processors case. This problem is much more 
complex, especially due to the presence of scheduling 
anomalies upon multiprocessors (see, e.g., chapter 5 
of HI on page 51 for a definition). Nowadays, it is 
well-known that real-time multiprocessor scheduling 
problems are typically not solved by applying straight- 
forward extensions of techniques used for solving similar 
uniprocessor problems. 

This research. In this paper, we propose a synchronous 
protocol without periodicity for the identical multipro- 
cessor case. Our proposal can be considered to be a 
multiprocessor extension of the Minimal Single Offset 
protocol, proposed in ||9l. 

Paper organization. In Section |2] we define the com- 
putational model used throughout the paper In Section |3] 
we propose a synchronous protocol without periodicity for 
the identical multiprocessor case, and in Section|4] we in- 
troduce future research directions. 

2 Model of computation 

We consider a multiprocessor platform composed of m 
identical processors denoted by "Pi, V2, . . ., Vm. We de- 
fine a multi-mode real-time system t as a set of x op- 
erating modes noted Mi,M2, . . .,Mx where each mode 
contains its own set of functionalities to execute. At any 
time during its execution the system runs in only one of 
its modes, meaning that it executes only the set of tasks 
associated with the selected mode. 

A mode Mk contains a set of Wjt functionalities, each 
modeled by a sporadic task = (C^^, D*^, T^), defined by 
three parameters - a worst-case execution time C*, a min- 
imal inter-arrival delay T'^ and a deadline Dj^ < - with 
the interpretation that the task generates successive jobs 
t'^ J (with = 1, . . . , oo) arriving at times e'^ . such that 

> + T'I (with e'^^ > 0), each such job has an 
execution requirement of at most and must be com- 
pleted at (or before) its deadline noted D'^ ^ ^. . + D^. 
Since D*^ < T^, successive jobs of a task x*^ do not inter- 



fere with each other Notice that a task must be enabled 
to generate jobs, and the system is said to run in mode 
only if every task of is enabled and all the tasks of the 
other modes are disabled. Thereby, disabling a task pre- 
vents it from releasing its future jobs. In our study, all the 
tasks of every mode are assumed to be independent, i.e., 
there is no communication, no precedence constraint and 
no shared resource (except the processors) between them. 

Every mode of the system uses its own schedul- 
ing algorithm noted S;c, which must guarantee that all the 
deadlines of the tasks of x'^ are met, when executed upon 
the m processors. In our study, we assume that Sjt is (1) 
global, i.e., a job may be assigned to any processor, (2) 
conservative, i.e., a processor cannot be idle if there is a 
pending job, and (3) must assign^xec/ job-level priorities, 
i.e., a job gets a priority as soon as it is released and keeps 
it constant until it completes. At run-time the scheduler 
assigns, at each time-instant, the m highest priority jobs 
(if any) to the m processors. Global-EDF and Global-DM 
(see e.g., [S)) are some examples of such schedulers. 

While the system is running in a mode M,, a mode 
change can be initiated by any task of x' or by the sys- 
tem itself, whenever it detects a change in the environment 
or in its internal state. This is performed by releasing a 
MCR(y) (i.e., a Mode Change Request), where My is the 
targeted destination mode. In the following, we denote by 
iyiCRd) '■^^ releasing time of a MCR(y). We assume that 
a MCR may only be produced in the steady state of the 
system, and not during the transition between two modes. 
Upon a MCR(/), the old-mode tasks (i.e., the tasks of the 
current mode M;) may have two distinct behaviors: either 
they must be aborted, or they have to complete the exe- 
cution of their last released job. We denote by C(f, /) the 
subset of tasks of x' which must complete their last in- 
stance when a MCR(/) occurs (and therefore x' \ C(i, ]) is 
the subset of tasks of x' which can be aborted). Notice that 
we do not consider mode-independent tasks in this paper. 

Whenever a MCR(;) occurs, the system immediately 
entrusts the scheduling decisions to a transition protocol. 
This protocol aborts all the task of x' \C(z, ;) and it disables 
all the tasks (if any) of C(z, ;'). Nevertheless, the last re- 
leased job of every task of C{i, j) is not aborted and must 
complete its execution. We call these jobs the rem-jobs 
hereafter. Since these rem-jobs may cause an overload if 
the tasks of %> are immediately enabled upon a MCR(;), 
the transition protocol usually has to delay the enablement 
of these tasks until it is safe to enable them. We denote by 
D{k, Mi, Mj) the relative deadline on the enabling time of 

the task x[ during the transition from the mode M, to the 
mode Mj, with the following interpretation: the transi- 
tion protocol must ensure that x^ is not enabled after time 
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*MCR(/) Mi, Mj). The goal of a transition protocol is 

therefore to complete every rem-job and to enable every 
task of the mode Mj, while meeting every job and en- 
ablement deadline. When all the rem-jobs are completed 
and all the tasks of are enabled, the system entrusts the 
scheduling decisions to the scheduler Sj of the mode Mj 
and the transition phase ends. 

3 Multiprocessor synchronous pro- 
tocol without periodicity 

In this section, we present our synchronous protocol with- 
out periodicity. The main idea is the following: upon a 
MCR(/), the rem-jobs continue to be scheduled by Si upon 
the m processors. When all of them are completed, all the 
new-mode tasks are simultaneously enabled. Figure [T]de- 
picts an example with a 2-processors platform. The modes 
Mi and My contain 4 and 3 tasks, respectively. The light 
and dark gray boxes are the old- and new-mode tasks, re- 
spectively. In this example, we consider that every task of 
t' belongs to C{i, j). 



ModeM^ in progress 



MCR{j) 



2,1 3,1 



release of every 
job of t' 



no more job of C{i,j) 
> enablement of every ta.sk of 
(end of the transition phase) 



Figure 1 : Illustration of a mode transition handled by our 
synchronous protocol. 

Definition 1 (a valid protocol) A transition scheduling 
protocol is said to be valid for a given multi-mode real- 
time system if it always meets all the job and enablement 
deadlines during the transition from any mode of the sys- 
tem to any other one. 

In order to know if a our protocol is valid for a given 
multi-mode system, we need to establish a schedulability 
condition, i.e., a condition based on the tasks and plat- 
form characteristics which indicates a priori whether the 
given system will always comply with the expected re- 
quirements during its execution. In the following, we first 
proof that every rem-job always meets its deadline during 
a transition from a mode M, to another mode My, when 
scheduled by S, upon the m processors. Then, we ex- 
press a sufficient schedulability condition which indicates 



if all the enablement deadlines are met during every mode 
change, while considering the worst-case scenario. 

Lemma 1 When a MCR(/) occurs at time fMCR(y) while 
the system is running in mode Mi, every rem-job issued 
from the tasks ofC(i, j) meets its deadline when scheduled 
by Si upon m processors. 

Proof From our assumptions, we know that the set of 
tasks t' is schedulable by Si upon m processors, and since 
Si assigns fixed job-level priorities, we know from SiSi 
that Si is predictable. By definition of the predictability 
(see ^ for details), if a set of jobs } = Ji, ■ ■ ■ , }n] 
( where each job /, = (fl,-, c,-, d,) is characterized by an ar- 
rival time Ui, a computing requirement Ci and a absolute 
deadline di) meets all the deadlines when scheduled by 
a predictable algorithm A upon m processors, then any 
set of jobs y = {}[, }'2, . . . , J'„}, where }'. = {ai,c'.,di) with 
c'j < Ci, also meets all the deadlines when scheduled by A 
upon the m processors. When the MCR(/) occurs at time 
^MCRO). every task of \ C{i, j) is aborted and every task 
of C{i, j) is disabled. Aborting and disabling these tasks 
is equivalent to set the execution requirement of all their 
jobs (or future jobs for the disabled tasks) to zero. Since 
Si is predictable, all the deadlines are still met when the 
rem-jobs are scheduled by Si upon the m processors. | 

From Lemma [U every rem-job always meets its dead- 
line when using our proposed protocol during the transi- 
tion. Thereby, our protocol is valid for a given real-time 
system if, for every mode transition, the maximal delay 
which may be produced by the rem-jobs is lower or equal 
than the enablement deadline of every new-mode task. 
That transition delay is equal to the completion time (also 
called makespan in the literature and hereafter) of all the 
rem-jobs and hence, we establish in the following lemma 
an upper bound on the makespan of a given set of n jobs 
/= l/i/ /2/ ■•■,/(! I of processing time pi,p2, ■ • ■ , P»- 

Lemma 2 Let } - [Ji, J2, ■ ■ ■ , }n] be a set of n jobs with 
processing times pi,p2/ ■ ■ ■ ,Pn which are ready for exe- 
cution at time 0. Suppose that these jobs are scheduled 
upon m identical processors (with m > \) by a global, 
conservative and fixed job-level priority scheduler What- 
ever the jobs priority assignment, an upper bound on the 
makespan is given by: 



upms(/,m) 



ifm > n 
otherwise 



(1) 



def 



where pmax = maxJLj{p,j. 

The proof is omitted in this version of the paper due to 
the space limitation. 
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Corollary 1 For any job /, of processing time and for 
any set of jobs J, we have upms{JU{} i],m) > upms(/, m). 

Corollary 2 For any set of jobs } and for any job /; e /, 
let ]'■ be a job such that p'- > pi. We have upms(/ \ {/,) U 
{}-},m) > upms(/,wz). 

In the framework of our problem, we know from Corol- 
lary [T] and |2] that the worst-case scenario occurs when (i) 
every task of C{i, j) releases a job exactly at time tucRij) 
and (ii) every released job has a processing time equal to 
the worst-case execution time of its task. Thus, a sufficient 
schedulability condition may be formalized as follows: 

SchedulabiUty Condition 1 For every transition from a 
mode Mi to another mode Mj, it must be the case where: 



upms(/,OT) < inin{D(fc, M„Mj)} 



ModcMj in progress 



MCR(j) 



where } {C|, 
by Equation\l\ 



e C{i, i)] and upms(/, m) is defined 



Open Problem 1 Instead of scheduling the rem-jobs by 
using the scheduler of the old-mode during the transi- 
tion, it could be better, in term of the enablement delays 
applied to the new-mode tasks, to propose a dedicated 
priority assignment which meets the deadline of every 
rem-job, while minimizing the makespan. To the best of 
our knowledge, the problem of minimizing the makespan 
while meeting job deadlines together is not addressed in 
the Uterature and remains for future work. 



4 Future work 

Our future work includes: 

1. Establishing a dedicated priority assignment, suit- 
able for scheduling the rem-jobs while minimizing 
their makespan. 

2. Proposing an asynchronous protocol without period- 
icity which aims to reduce the enablement delay ap- 
plied to the new-mode tasks, by enabling them as 
soon as possible. The main idea of that protocol 
is depicted in Figure |2] When a processor has no 
more rem-job to execute, some new-mode tasks are 
immediately enabled. However, since multiproces- 
sor schedules suffer from scheduling anomalies, im- 
mediately enabling the new-mode tasks must be car- 
ried out very carefully, in order to not jeopardize the 
schedulability of the new-mode. 



Mj begins 



release of every 
job of t' 



enablement of some 
tasks of t/ 



no more job of C{i,j) 
p enablement of every task of t! 
(end of the transition phase) 



Figure 2: Illustration of a mode transition handled by our 
asynchronous protocol. 
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